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(54) Optimization of memory usage based on garbage collection simulation 



(57) A method for optimization of memory usage for 
a computer application. Memory usage data (720) is re- 
ceived (215) wherein the memory usage data (720) 
comprises timing information. A graphical representa- 



tion (740) of the memory usage data (720) is generated 
(225). At least one heap parameter (725) is received 
(230). A memory usage simulation is performed (245) 
based on the memory usage data (720) and the heap 
parameter (725). 
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Description 

[0001] The present invention relates to a method of 
and apparatus for optimising memory usage. 
[0002] Many modem programming languages pro- 5 
vide facilities for dynamic allocation of memory for ob- 
jects or other data structure instances created by appli- 
cations at run-time. Some languages such as C and Cf+ 
require explicit user action for reclaiming such dynami- 
cally allocated memory, while other languages such as 10 
Java and C# provide support for memory management 
that enables automatic reclamation of dynamically allo- 
cated memory. For example, the Java programming lan- 
guage allocates objects within the Java Virtual Machine 
(JVM) heap. When an object is no longer required, it is is 
not explicitly released or removed from the heap. In or- 
der to remove unused objects, Java provides a built in 
capability for the collection of unreferenced dynamically 
allocated objects, herein referred to as "garbage. 0 The 
automatic memory management capabi Irty is commonly 20 
referred to as "garbage collection" . 
[0003] Garbage collection provides the ability to re- 
lease and reclaim memory when it is no longer required, 
thus providing a paradigm that enables the creation of 
more efficient applications. However, garbage collection 25 
itself adds a performance overhead to many Java appli- 
cations. In particular, Java enterprise applications that 
utilize significant system memory resources can be per- 
formance or capacity impaired based on the garbage 
collection activity that they produce as the workload they 30 
are processing increases. This leads to slow and some- 
times unreliable operation of Java enterprise applica- 
tions. 

[0004] Except for the situations where garbage col- 
lection overhead is a direct result of software defects, 35 
non-optimal heap memory usage and incorrect policy 
choices for the garbage collector are the primary causes 
of increased garbage collection overhead. The process 
of configuring the heap for optimal memory usage and 
fine-tuning the garbage collector policies is referred to 40 
as "garbage collector tuning." 

[0005] Garbage collector tuning can yield a very large 
performance payoff (e.g. , 1 00 percent, or even substan- 
tially higher) on certain enterprise applications by opti- 
mizing the heap memory usage and reducing the total 45 
time spent in garbage collection. This enables one to 
achieve predictable and optimal performance of appli- 
cations, written in Java or similar programming languag- 
es. 

[0008] Current garbage collection tools are integrated so 
as part of Java profiling or monitoring solutions. These 
tools typically rely on measuring heap capacity using ei- 
ther published Java interfaces, or rely on the garbage 
collection trace option available in an implementation of 
the JVM. While these tools provide a user with some ss 
guidance for optimizing garbage collection, these tools 
have a number of drawbacks. Most significantly, these 
tools do not provide any guidance on the actual optimal 



garbage collection parameters, and provide no relief 
from the expensive process described below. 
[0007] Figure 1 is a flowchart diagram illustrating a 
process 1 00 for garbage collection tuning in accordance 
with the prior art. At step 1 05, the memory allocation be- 
havior trace used to configure the garbage collection is 
specified to the interpreter. At step 110, an application 
is executed for the programming language which the ap- 
plication was written in. At step 115, the trace data is 
analyzed. At step 120, it is determined whether or not 
the desired results were achieved. If so, process 100 
ends. Alternatively, if desired results were not achieved, 
as shown at step 1 25, the heap parameters are adjusted 
based on the analysis and process 100 returns to step 
105. 

[0008] Typically, garbage collection is subject to user- 
entered or default parameters. In order to determine 
which parameters to insert, a user must run the appli- 
cation and analyze the results of the Java heap behav- 
ior. For example, a user must perform a run of the ap- 
plication to allow for collection of heap behavior data, 
and analyze the results. While the overall garbage col- 
lection time may be small, garbage collections may take 
a substantial amount of the overall execution time for 
large applications, such as enterprise applications. For 
example, the garbage collection on a large application 
dominate the overall execution time. Upon completing 
a run of the application, the heap behavior data is ana- 
lyzed and the new parameters are specified by the user 
based on this analysis. This process is repeated until 
the desirable parameters are entered. 
[0009] Furthermore, in order to optimize garbage col- 
lection, a user must determine new parameters when- 
ever the application is changed or whenever the plat- 
form is changed. The time spent running the application, 
collecting the heap behavior data, and analyzing the re- 
sults can be sizable, resulting in substantial costs to 
those running the applications. 
[001 0] Additional problems arise when the application 
being analyzed is being diagnosed off-site. It is typically 
too cumbersome to install an application, particularly on 
a third party computer system. Furthermore, the owner 
of the application may not want to install the application 
on a third party computer system due to privacy con- 
cerns. As such, a third party must tell the user which 
parameters to enter, then wait until the application is run , 
and the heap behaviour data is collected. This con- 
sumes the computing resources of the application own- 
er, and may impose extra costs beyond those associat- 
ed directly with running the application (e.g., network 
downtime and lowered performance of other applica- 
tions). 

[0011] The present invention seeks to provide im- 
proved memory usage. 

fl)01 2] According to an aspect of the present invention 
there is provided a method of optimising memory usage 
as specified in claim 1 . 

[001 3] According to another aspect of the present in- 
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vention there is provided a computer readable medium 
having computer-readable program code embodied 
therein for causing a computer system to perform a 
method for simulating collection of unreferenced ob- 
jects, said method comprising: 

a) accessing unreferenced object collection data 
comprising timing data; 

b) illustrating a viewable depiction of said unrefer- 
enced objection collection data; 

c) accessing at least one memory criterion; 

d) executing an unreferenced objection collection 
simulation based on said unreferenced objection 
collection data and said memory criterion; and 

e) illustrating a viewable depiction of said garbage 
collection simulation. 

[001 4] According to another aspect of the present in- 
vention there is provided a computer system compris- 
ing: 

a bus; 

a computer-readable memory coupled to said bus; 
and 

a processor coupled to said bus, said processor for 
performing a method of garbage collection simula- 
tion, said method comprising: 

a) receiving garbage collection data comprising 
timing data; 

b) rendering a visual portrayal of said garbage 
collection data; 

c) receiving at least one heap input; 

d) executing a garbage collection simulation 
based on said garbage collection data and said 
heap input; and 

e) rendering a visual portrayal of said garbage 
collection simulation. 

[0015] According to another aspect of the present in- 
vention there is provided a method of simulating mem- 
ory usage comprising: 

a) receiving memory usage data; 

b) determining a simulation model based on said 
memory usage data; 

c) determining heap configuration and heap policies 
based on said memory usage data; 

d) receiving at least one heap parameter; 

e) determining simulation characteristics for at least 
one measurement interval of said memory usage 
data; and 

f) simulating an application run based on said sim- 
ulation characteristics. 

[0016] In the method for optimization of memory us- 
age for a computer application presented, memory us- 
age data is received wherein the memory usage data 
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comprises timing information. A graphical representa- 
tion of the memory usage data is generated. At least 
one heap parameter is received. A memory usage sim- 
ulation is performed based on the memory usage data 
and the heap parameter. 

[0017] Embodiments of the present invention are de- 
scribed below, by way of example only, with reference 
to the drawings, in which: 

FIGURE 1 is a flowchart diagram illustrating a proc- 
ess for garbage collection tuning in accordance with 
the prior art. 

FIGURES 2A and 2B are a flowchart diagram illus- 
trating a process for selecting a parameter for gar- 
bage collection tuning in accordance with an em- 
bodiment of the present invention. 

FIGURE 3 is an exemplary screen shot of garbage 
collection duration view generated by a garbage 
collection simulator graphical user interface in ac- 
cordance with one embodiment of the present in- 
vention. 

FIGURE 4 is an exemplary screen shot of a sum- 
mary view generated by a garbage collection sim- 
ulator graphical user interface in accordance with 
one embodiment of the present invention. 

FIGURE 5 is an exemplary screen shot of a heap 
parameter input view generated by a memory us- 
age simulator graphical user interface in accord- 
ance with one embodiment of the present invention. 

FIGURE 6 is a flowchart diagram illustrating a proc- 
ess for simulating a garbage collection in accord- 
ance with one embodiment of the present invention. 

FIGURE 7 is a data flow diagram illustrating data 
flow between a Java Virtual Machine and a garbage 
collection simulator in accordance with one embod- 
iment of the present invention. 

[001 8] Reference will now be made in detail to the pre- 
ferred embodiments of the invention, examples of which 
are illustrated in the accompanying drawings. The dis- 
closure is intended to cover alternatives, modifications 
and equivalents, which may be included within the 
scope of the invention as defined by the appended 
claims. Furthermore, in the following detailed descrip- 
tion, numerous specific details are set forth in order to 
provide a thorough understanding of the teachings here- 
in. However, it will be apparent to one skilled in the art 
that they may be practised without these specific details. 
[0019] Figures 2A and 2B are a flowchart diagram il- 
lustrating a process 200 for simulating programming 
language memory usage in accordance with an embod- 
iment of the present invention. In one embodiment, 
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process 200 is carried out by processors and electrical 
components under the control of computer readable and 
computer executable instructions. The computer read- 
able and computer executable instructions reside, for 
example, in data storage features such as a computer 5 
usable volatile memory and/or computer usable non- 
volatile memory. However, the computer readable and 
computer executable instructions may reside in any type 
of computer readable medium. Although specific steps 
are disclosed in process 200, such steps are exemplary, i o 
That is, the embodiments of the present invention are 
well suited to performing various other steps or varia- 
tions of the steps recited in Figures 2A and 2B. 
[0020] At step 205 of Figure 2A, the memory alloca- 
tion behavior trace used to configure the garbage col- is 
lection is specified to the interpreter. In one embodi- 
ment, the interpreter is a Java virtual Machine (JVM). 
The memory allocation behavior trace is a mechanism 
that captures information that is necessary and suffi- 
cient for conducting an offline simulation and that can 20 
be collected with minimal intrusion on the executing ap- 
plication. In one embodiment, the memory allocation be- 
havior trace is the -Xverbosegc option on HP-UX. In one 
embodiment, the memory allocation behavior trace data 
comprises information regarding the collection of gar- 25 
bage, and is also referred to herein as memory usage 
data. For clarification, memory usage data is also re- 
ferred to herein as garbage collection data, memory al- 
location behavior trace, and detailed garbage collection 
trace data. Generally, the memory usage data is a file 30 
in tabular form comprising detailed information regard- 
ing events and operations occurring during a garbage 
collection. In one embodiment, the memory usage data 
includes, but is not limited to: 

35 

• why the garbage collection was performed; 

• how long the garbage collection took; 

• the time the garbage collection occurred; 

• how much memory was collected by this specific 
garbage collection (e.g., how efficient this particular <o 
garbage collection was); 

• detailed information about heap capacity; 

• what portion of each of the individual segments was 
used before the garbage collection; 

• what portion of each of the individual segments was 45 
used after the garbage collection; and 

• what is the approximate age of objects deemed to 
beW. 

[0021] In one embodiment, where the application is so 
Java-based, the memory usage data is produced by se- 
lecting the -Xverbosegc option in the JVM garbage col- 
lector. 

[0022] At step 21 0, an application is executed for the 
programming language which the application was writ- ss 
ten in. In one embodiment, the application is an enter- 
prise application. In one embodiment, the application is 
a Java-based application, written in a Java-based pro- 



gramming language. In the present embodiment, the in- 
terpreter is a JVM. For purposes of the present applica- 
tion, the interpreter is referred to as a JVM for Java- 
based programming languages, however, it should be 
appreciated that this embodiment is intended for use 
with any programming language that utilizes collection 
of unreferenced dynamically allocated objects (e.g., 
garbage) to free unused memory. 
[0023] At step 21 5, the garbage collection data (e.g. , 
memory allocation behavior trace data, memory usage 
data, unreferenced object collection data) is received at 
a garbage collection simulator. In one embodiment, 
where the garbage collection simulator resides in the 
JVM, the memory usage data is accessed directly. In 
another embodiment, the memory usage data is trans- 
mitted to the garbage collection simulator as an email 
attachment. In another embodiment, the memory usage 
data is transmitted as a file on a floppy disk. It should 
be appreciated that the memory usage data is generally 
a small file, and is easy to transfer from computer sys- 
tem to computer system. 

[0024] At step 220, the garbage collection simulator 
is accessed. The garbage collection simulator compris- 
es a graphical user interface that provides a user-friend- 
ly mechanism for analyzing and adjusting heap param- 
eters, and for viewing the results of a garbage collection 
simulation. In one embodiment, the garbage collection 
simulator resides on the same computer system as the 
JVM. In another embodiment, the garbage collector sim- 
ulator is accessed over a network connection. 
[0025] At step 225, a graphical representation of the 
memory usage data is generated. As described above, 
the memory usage data is in tabular form, and is ame- 
nable to having a plurality of data plots generated there- 
from. In one embodiment, a plurality of data plots are 
generated to illustrate different aspects of the garbage 
collection. 

[0026] In particular, the timing information as captured 
in the memory usage data allows for plotting various in- 
formation versus the overall time of the application's ex- 
ecution. Figure 3 is an exemplary screen shot 300 of a 
garbage collection duration data plot 305 generated by 
a garbage collection simulator graphical user interface 
in accordance with one embodiment of the present in- 
vention 

[0027] Data plot 305 comprises an x-axis 310 com- 
prising the overall application run time in seconds and 
a y-axis 315 comprising the run time of a specific gar- 
bage collection routine in seconds. Furthermore, data 
plot 305 illustrates the duration of four types of garbage 
collection routines: scavenge, system. gc, old full, and 
old too full. Specifically, data plot 305 illustrates when a 
garbage collection occurred, what type of garbage col- 
lection occurred, and how long it took to run. Overall tim- 
ing information, such as the average scavenge garbage 
collection duration and the average full garbage collec- 
tion duration are shown in timing information 320. 
[0028] With reference to step 225 of Figure 2A, a wide 



4 



7 



EP 1 349 077 A2 



8 



variety of data plots or graphical representations can be 
generated using the memory usage data. In one embod- 
iment, additional data plots include, but are not limited 
to: heap usage versus time; cumulative bytes freed ver- 
sus time; and creation rate. Embodiments of the present 
invention are directed to permitting user-defined graph- 
ical representations of data. A user desiring specific gar- 
bage collection information may generate a data plot 
based on requested inputs. 

[0029] In one embodiment, the memory usage data is 
presented in a text format illustrating a summary of gar- 
bage collection activity during the application run time. 
Figure 4 is an exemplary screen shot 400 of summary 
view 405 generated by a garbage collection simulator 
graphical user interface in accordance with one embod- 
iment of the present invention. Summary view 405 illus- 
trates detailed information concerning the heap capacity 
of the JVM, the garbage collection activity, and overall 
statistics. Timing information 41 0 comprises information 
detailing how much time was spent in garbage collec- 
tion. Pie chart 415 is another graphical representation 
of the fraction of overall run time spent in garbage col- 
lection. 

[0030] With reference to step 225 of Figure 2A, a user 
is presented with a number of graphical representations 
of garbage collection information. Using these graphical 
representations, a user can analyze the garbage collec- 
tion activities of an application. Based on the information 
presented in the graphical representations, a user may 
desire to change various input parameters in order to 
optimize the performance of the application. 
[0031] At step 230 of Figure 2B, at least one heap pa- 
rameter (e.g., a parameter, a memory criterion, or a 
heap input) is received at the garbage collection simu- 
lator. In one embodiment, a user-entered heap param- 
eter is received at the garbage collection simulator. It 
should be appreciated that a heap parameter can be 
computer generated, and that this embodiment is not 
intended to be limited to user-generated input for heap 
parameters. 

[0032] Figure 5 is an exemplary screen shot 500 of a 
heap parameter input view 505 generated by a garbage 
collection simulator graphical user interface in accord- 
ance with one embodiment of the present invention. 
Heap parameter input view allows for a userto configure 
the garbage collection of an application by altering var- 
ious heap parameters. In one embodiment, there are 
four heap parameters: total heap size 510, new gener- 
ation size 515, survivor ratio 520, and calls to system, 
gc indicator 525. 

[0033] In one embodiment, heap parameter input 
view 505 presents the heap parameters as they exist in 
the application as run. A user then changes the values 
of the heap parameters relative to the original value. For 
example, where the JVM has a total heap size 510 of 
64 MB, the heap parameter input view illustrates the val- 
ue 64 MB associated with total heap size 510. A user 
may then change the value of total heap size 51 0, hav- 



ing been made aware of the original value. 
[0034] In one embodiment, the heap parameter val- 
ues fortotal heap size 51 0, new generation size 51 5 and 
survivor ratio 520 can be changed by directly entering 
s text into a text box (e.g., text box 512a-c). In one em- 
bodiment, the heap parameter values fortotal heap size 
51 0, new generation size 515 and survivor ratio 520 can 
be changed by moving a slider (e.g., slider 514a-c). In 
one embodiment the value depicted in text box 512 is 

10 updated as slider 51 4 is moved. In another embodiment, 
the value depicted by slider 514 is updated as a new 
value is entered into text box 512. 
[0035] In one embodiment, indicator 525 is a check 
box indicating whether application initiated requests to 

15 perform memory management are included in the appli- 
cation run. ff the application has initiated such requests, 
based on the trace data, this box is initially checked. A 
user may check or uncheck the box depending on the 
nature of the application. 

20 [0036] In one embodiment, heap parameter input 
view 505 comprises a JVM selector 530. In one embod- 
iment, the JVM selector 530 is a pull-down menu com- 
prising a plurality of JVM versions. JVM selector initially 
illustrates which JVM version/type was used in the ap- 

25 plication run, with the ability to produce JVM options for 
other JVM versions/types. A user can change the JVM 
version/type options that are necessary for re-running 
their application by selecting a different JVM version. 
Once a user has entered in the desired heap parame- 

30 ters, a simulation is executed by activating simulation 
activator 540. 

[0037] In one embodiment, heap parameter input 
view 505 comprises JVM options 535. JVM options 535 
is a text string comprising the values selected for total 

35 heap size 51 0, new generation size 515, survivor ratio 
520, and calls to system.gc indicator 525. JVM options 
535 can be copied directly in the JVM once the desired 
heap parameters have been attained. 
[0038] At step 235 of Figure 2B, the workload charac- 
teristics are modified. It shou Id be appreciated that step 
235 is optional, and that the workload characteristics 
may remain the same. At step 240, the garbage collec- 
tion simulator configuration is modified. It should be ap- 
preciated that step 240 is optional, and that the garbage 

45 collection simulator configuration may remain the same. 
[0039] At step 245 of Figure 2B, a garbage collection 
simulation (e.g., memory usage simulation) is executed. 
In one embodiment, selecting a simulation activator (e. 
g., simulation activator 340 of Figure 3) activates the 

so garbage collection simulation. The garbage collection 
simulation is based on the memory usage data and the 
input parameters. 

[0040] Figure 6 is a flowchart diagram illustrating a 
process 600 for simulating a garbage collection (e.g., 
& memory . usage) in accordance with an embodiment of 
the present invention. At step 605, detailed garbage col- 
lection trace data is received. In one embodiment, the 
garbage collection trace data is acquired through the 
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-Xverbosegc option on HP-UX. In one embodiment, the 
garbage collection trace data comprises information re- 
garding the collection of garbage, and is also referred 
to herein as garbage collection data. 
[0041] At step 610, it is determined what simulation 
model should be used based on the format of the gar- 
bage collection trace data. At step 61 5, the original h eap 
configuration and policies are determined based on the 
input garbage collection trace data. At step 620, at least 
one adjustment to a heap parameter is received. It 
should be appreciated that the adjustments may be 
made to the heap configuration, the work load charac- 
teristics, or the simulator parameters. 
[0042] At step 625, simulation characteristics are de- 
termined for each measurement interval represented in 
the trace data. In one embodiment, the simulation char- 
acteristics comprise: 

• determine total memory allocated; 

• determine total memory that is collected; 

• estimate the memory allocation rate; and 

• estimate the rate at which memory becomes unref- 
erenced. 

[0043] At step 630, a new application run is simulated 
based on the simulation characteristics determined at 
step 625. In one embodiment, the garbage collection 
simulation data estimated for the modified heap config- 
uration includes, but is not limited to: 

• the intervals between garbage collection; 

• the duration of each of the individual collections; 

• the cause for each garbage collection; 

• the total memory allocated between two collections; 

• the total memory collected between two collections; 

• the duration of each individual garbage collection; 
and 

• an estimation of the distribution of memory usage 
by age. 

[0044] At step 250 of Figure 2B, an analysis and 
graphical representation of the garbage collection sim- 
ulation data is generated. In one embodiment, the gar- 
bage collection simulation data is in tabular form, and is 
amenable to having a plurality of data plots generated 
therefrom. In one embodiment, a plurality of data plots 
are generated to illustrate different aspects of the gar- 
bage collection simulation. In particular, garbage collec- 
tion simulation data comprises timing information that 
allows for plotting various information versus the overall 
time of the application's execution. 
[0045] It should be appreciated that the graphical rep- 
resentation generated for the garbage collection simu- 
lation data is similar to that generated for the garbage 
collection data at step 225 of Figure 2A. For example, 
exemplary screen shot 300 of Figure 3 is also an illus- 
tration of a garbage collection duration data plot 305 
based on the garbage collection simulation data. 



Likewise, exemplary screen shot 400 of Figure 4 is also 
an illustration of summary view 405 based on the gar- 
bage collection simulation data. 
[0046] As with the garbage collection data, a wide va- 

s riety of data plots or graphical representations can be 
generated using the garbage collection simulation data. 
In one embodiment, additional data plots include, but 
are not limited to: heap usage versus time; cumulative 
bytes freed versus time; and creation rate. Embodi- 

io ments of the present invention are directed to permitting 
user-defined graphical representations of data. A user 
desiring specific garbage collection information may 
generate a data plot based on requested inputs. 
[0047] In one embodiment, a graphical representation 

15 is generated comparing the garbage collection simula- 
tion data with the garbage collection data. In another 
embodiment, a graphical representation is generated 
comparing the garbage collection simulation data with 
another set of garbage collection simulation data. It 

20 should be appreciated that any number of garbage col- 
lection simulation data sets can be compared. The com- 
parison graphical representation allows a user to ana- 
lyze the performance of a plurality of different sets of 
heap parameters for the same application, thus allowing 

25 the user to select a desirable set of heap parameters for 
the application. 

[0048] A user is presented with a number of graphical 
representations of garbage collection simulation infor- 
mation. Using these graphical representations, a user 

30 can analyze the garbage collection activities of an ap- 
plication. Based on the information presented in the 
graphical representations, a user may desire to change 
various input parameters in order to optimize the per- 
formance of the application and rerun the simulation. 

35 [0049] At step 255, it is determined whether or not to 
run another simulation. In one embodiment, this deter- 
mination is made by a user. Provided the user decides 
to run another simulation, process 200 returns to step 
230, where at least one new heap parameter is entered. 

40 Alternatively, provided the user does not want to run an- 
other simulation, process 200 continues on to step 250. 
[0050] At step 260 of Figure 2A, the optimized heap 
parameters are inserted into the JVM. In one embodi- 
ment, the heap parameters are provided by the garbage 

4£ collection simulator as a character string (e.g., JVM op- 
tions 535 of Figure 5). In one embodiment, the character 
string is inserted directly into the JVM by the garbage 
collection simulator. In another embodiment, a user can 
copy and paste the character string from the garbage 

so collection simulator directly into the JVM. 

[0051 ] At step 265, it is determined whether or not to 
continue the analysis of the simulation results is. In one 
embodiment, this determination is made by a user. Pro- 
vided the user decides to continue the analysis, process 

55 200 returns to step 21 0. Alternatively, provided the user 
decides not to continue the analysis, process 200 con- 
tinues on to step 270. 

[0052] At step 270, the application is executed within 
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the JVM with the optimized heap parameters. It should 
be appreciated that step 270 is optional, and that opti- 
mized heap parameters can be relied on. However, be- 
cause the optimized heap parameters are the result of 
a simulation, it may be desirable to run the application 
with the optimized heap parameters to ensure their ef- 
fectiveness. 

[0053] Figure 7 is a data flow diagram 700 illustrating 
data flow between a JVM 705 and a memory usage sim- 
ulator 715 (e.g., a garbage collection simulator) in ac- 
cordance with one embodiment of the present invention. 
It should be appreciated that JVM 705 and memory us- 
age simulator 715 may reside on the same computer 
system or on different computer systems. The data 
transferred between JVM 705 and memory usage sim- 
ulator 715 (e.g., memory usage data 720 and optimized 
parameters 745) is generally small, and is easy to trans- 
fer regardless of where JVM 705 and memory usage 
simulator 715 reside. 

[0054] Java-based application 71 0 is executed within 
JVM 705, wherein a memory usage data 720 is gener- 
ated. Memory usage data 720 is transmitted to memory 
usage simulator 715. Memory usage data 720 compris- 
es memory usage information including timing informa- 
tion concerning each garbage collection. Memory usage 
simulator 71 5 generates a graphical representation 740 
of the memory usage data. 

[0055] I n response to grap hical representation 740, at 
least one parameter 725 is inputted into memory usage 
simulator 715. Optionally, workload characteristics 730 
and simulator configuration 735 are inputted into mem- 
ory usage simulator 715. Based on memory usage data 
720 and input heap parameters 725, a simulation is ex- 
ecuted. Specifically, based on memory usage data 720, 
a number of assumptions are made. For example, a lin- 
ear rate of allocations between garbage collections is 
assumed. By assuming the behavior of the garbage col- 
lections, a simulation can be performed accounting for 
changes in the heap parameters. It should be appreci- 
ated that other embodiments of the invention could 
make different assumptions. 

[0056] Upon completion of the simulation, in one em- 
bodiment, graphical representation 740 is updated to 
display the results of the simulation. It should be appre- 
ciated that the simulation can be repeated any number 
of times for various heap parameters 725. Upon deter- 
mination that the heap parameters are optimized, the 
optimized heap parameters 745 are inserted into the 
JVM. 

[0057] The preferred embodiment of the present in- 
vention, a method for optimization of memory usage for 
a computer application, is thus described. While the 
present invention has been described in particular em- 
bodiments, it should be appreciated that the present in- 
vention should not be construed as limited by such em- 
bodiments, but rather construed according to the ap- 
pended claims. 

[0058] The disclosures in United States patent appli- 



cation No. 1 0/1 04751 , from which this application claims 
priority, and in the abstract accompanying this applica- 
tion are incorporated herein by reference. 

5 

Claims 

1. A method of optimizing memory usage for a com- 
puter application (710), including the steps of: 

10 

a) receiving (215) application memory usage 
data (720), said application memory usage da- 
ta (720) comprising timing information; 

b) generating (225) a graphical representation 
15 (740) of said application memory usage data 

(720); 

c) receiving (230) at least one heap parameter 
(725); and 

d) performing (245) a memory usage simulation 
20 based on said application memory usage data 

(720) and said heap parameter (725). 

2. A method as recited in claim 1 , wherein said com- 
puter program (71 0) Is Java-based. 

25 

3. A method as recited in claim 1 or 2, including the 
step of inserting (260) said heap parameter into a 
programming language interpreter (705). 

30 4. a method as recited in claim 3, wherein said pro- 
gramming language interpreter (705) is a Java Vir- 
tual Machine. 

5. A method as recited in any preceding claim, where- 
35 in said heap parameter (725) is received in re- 
sponse to a user input. 

6. A method as recited in any preceding claim, includ- 
ing the step of repeating steps c) and d) to optimize 

40 garbage collection. 

7. A method as recited in any preceding claim, includ- 
ing the step of generating (250) a graphical repre- 
sentation (740) of garbage collection simulation. 

45 

8. A method as recited in any preceding claim, where- 
in said memory usage data (720) is received from 
a memory allocation behaviour trace. 

50 9. A method as recited in claim 8, wherein said mem- 
ory allocation behaviour trace is recorded as -Xver- 
bosegc data. 

1 0. A method as recited in any preceding claim, where- 
as in step d) includes the steps of: 

receiving (605) said memory usage data; 
determining (61 0) a simulation model based on 
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said memory usage data; 
determining (61 5) heap configuration and heap 
policies based on said memory usage data; 
receiving (620) at least one said heap parame- 
ter; 

determining (625) simulation characteristics for 
at least one measurement interval of said mem- 
ory usage data; and 

simulating (630) an application run based on 
said simulation characteristics. 
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